[% setvar title The Perl 6 Summary for the week ending 20021103 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20021103'></a><h1>The Perl 6 Summary for the week ending 20021103</h1>
<p>Welcome to the latest of the ongoing series of Perl 6 summaries, in
which your arrogant moderator does battle with the forces of prolixity
in a Brobdingnagian attempt to tame the tortuously tangled threads of
Perl 6's design and development mailing lists. And if I keep up the
purple prose at that rate it'll *still* be clearer than the tangle
that is this week's perl6-language discussion.</p>
<p>However, because it's customary, and because the language list scares
me, we'll start with the comparatively tame perl6-internals.</p>
<a name='Fun with file formats'></a><h2>Fun with file formats</h2>
<p>Toward the end of last week, Rhys Weatherley had asked about being
able to insert arbitrary chunks of metadata into parrot bytecode
files. Dan ended up producing a `draft sketch' of the bytecode
generation facilities and the ability to add arbitrary chunks of
metadata was conspicuous by its absence. People didn't seem to be
happy about this, lamenting a lack of flexibility, both in the overall
file structure and in what one could stick into the bytecode. Dan
mounted a sturdy defence, pointing out that we want ` a file format
that does what we need it to--present executable bytecode data to the
interpreter--as fast as possible. Everything else is secondary to
that.'</p>
<p>Kv Org wondered if it would be a good idea to worry about sandbox
issues in the bytecode format, but nothing came of that
question. Well, not this week anyway.</p>
<p><a href='http://groups.google.com/groups?threadm=00ab01c27cb2$bb206300$7b01a8c0@deepblue' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=20021027211330.71710.qmail@onion.perl.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=a05111b09b9e46aae3b80@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<p><a href='http://groups.google.com/groups?threadm=20021030221715.73307.qmail@web13206.mail.yahoo.com' target='_blank'>groups.google.com</a></p>
<a name='Portable linking issues'></a><h2>Portable linking issues</h2>
<p>Andy Dougherty is having portability problems. He wants to portably
compile and link 3 files and he's having problems and wondered what
the best way forward was to get an early test compiling properly on
all platforms. Help was supplied, the build was fixed, and the world
remained safe for democracy. (Modulo a few local difficulties.)</p>
<p><a href='http://groups.google.com/groups?threadm=Pine.SOL.4.10.10210281229360.23168-100000@maxwell.phys.lafayette.edu' target='_blank'>groups.google.com</a></p>
<a name='Implicit stack direction probe'></a><h2>Implicit stack direction probe</h2>
<p>Meanwhile, Jason Gloudon's patch to move the stack direction probe
back to initialization time rather that compile time was offered. I'm
assuming that Nicholas Clark's suggested speedup trick from last week
was implemented as part of it, but I'm no great understander of C.</p>
<p><a href='http://rt.perl.org/rt2/Ticket/Display.html?id=18127' target='_blank'>rt.perl.org</a></p>
<a name='Of MOPS and Microops'></a><h2>Of MOPS and Microops</h2>
<p>There's been some discussion of granting a small number of Parrot
registered 'most favoured' status. The idea being that a small number
of registers would actually be held in global (possibly real register)
variables, with the rest being accessed through via indirection
through the interpreter. Apparently the JIT core already does some
optimization along these lines, and Dan doesn't seem to be sure that
doing it for the main interpreter would actually be much of
win. Discussion continues.</p>
<p><a href='http://groups.google.com/groups?threadm=a05111b03b9e358db9680@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<a name='Very complete lexical scopes'></a><h2>Very complete lexical scopes</h2>
<p>Jonathan Sillito has submitted a patch which `implements a very
complete set of lexical scope semantics'. It looks pretty cool to my
untutored eye. General response was positive, though J&uuml;rgen
B&ouml;mmels did have a query about how to create a new scope.</p>
<p><a href='http://rt.perl.org/rt2/Ticket/Display.html?id=18170' target='_blank'>rt.perl.org</a></p>
<a name='miniparrot, a first attempt'></a><h2><b><i>miniparrot</i></b>, a first attempt</h2>
<p>If you've been paying attention to the Parrot build process, you'll be
aware that it was always a goal to use a cut down variant of parrot
itself to run the configuration tests. The plan is that this
<b><i>miniparrot</i></b> should be buildable with nothing more than an ANSI
compliant C compiler. Josh Wilmes thinks we're about ready to start
building said miniparrot, and offered his first cut to the
list. Response was positive, with quibbles, which is about what one
would expect.</p>
<p><a href='http://groups.google.com/groups?threadm=200211010345.gA13jUJ2005602@galactic.hitchhiker.org' target='_blank'>groups.google.com</a></p>
<a name='Meanwhile, over in perl6-language (or &quot;The Horror! The Horror!&quot;)'></a><h1>Meanwhile, over in perl6-language (or &quot;The Horror! The
Horror!&quot;)</h1>
<p>The dreaded `Operator Reshuffle' thread continues apace -- of the 450
posts last week I'd say about 400 of 'em were discussing various
aspects. Bear in mind too that the path of discussion could be
described as helical (sort of like circular, but getting more and more
wound up with each go 'round). There are at least two factions
involved, roughly caricatured as `Simon Cozens vs. The Rest of the
World'. Simon can be thought of as the voice of conservatism (or
Reason, depending on whether you agree with him or not), generally
arguing against stuff he considers massively ugly or
confusing. Simon's allies vary depending on which issue he's
discussing and his worries include:</p>
<ul>
<li><a name='Perl 6 is going to be even harder to parse than Perl 5'></a>Perl 6 is going to be even harder to parse than Perl 5</li>
<li><a name='Unicode operators in the core language are Just Wrong. Lots of people agree with him on this.'></a>Unicode operators in the core language are Just Wrong. Lots of people
agree with him on this.</li>
<li><a name='Superpositional operators will be too rare to justify giving them precious one character operators.'></a>Superpositional operators will be too rare to justify giving them
precious one character operators.</li>
</ul>
<p>This is, of course a gross simplification of what's going on in the
various operator threads, but it does cover a fair number of the
issues that are arising in the attempt to get <code>^</code> back as exclusive
or (which then frees <code>~</code> up to become string concatenate,
which... ah, go read last week's summary, I already did this...)</p>
<p>BTW, 'Vectorizing' is the new 'Hyperizing' (or did I do that last
week?)</p>
<p>Here's the various threads involved in the kerfuffle, along with
Michael Lazzaro's utterly wonderful summaries of the current core
operator list as he sees it.</p>
<p><a href='http://groups.google.com/groups?threadm=3DBC5347.6DB387E4@cognitivity.com' target='_blank'>groups.google.com</a> -- Op list, Take 3.</p>
<p><a href='http://groups.google.com/groups?threadm=C3D428ED-EABB-11D6-A0B2-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a> -- Take 4</p>
<p><a href='http://groups.google.com/groups?threadm=43215E86-EBA5-11D6-AC84-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a> -- Take 5</p>
<p><a href='http://groups.google.com/groups?threadm=63ED27DD-EBA5-11D6-AC84-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a> -- Take 5a</p>
<p><a href='http://groups.google.com/groups?threadm=E3FD6D2B-EC68-11D6-B3E1-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a> -- Take 5b</p>
<p><a href='http://groups.google.com/groups?threadm=8964D98F-EDD7-11D6-8B40-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a> -- Take 6</p>
<p><a href='http://groups.google.com/groups?threadm=00A132CC-ECF7-11D6-9717-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a> -- Pointers to
Unicode stuff</p>
<p><a href='http://groups.google.com/groups?threadm=20021031111328.A6143@rama.comp.pge.com' target='_blank'>groups.google.com</a> -- Someone coming in late</p>
<p><a href='http://groups.google.com/groups?threadm=847kg1ol2a.fsf@despairon.bofh.org.uk' target='_blank'>groups.google.com</a> -- Questioning the value of
infix superpositions</p>
<a name='Smalltalk type collection classes?'></a><h2>Smalltalk type collection classes?</h2>
<p>One of the subthreads of the mammoth operator thread covered whether it
might be a good idea to include a set of Collection classes in the
style of the Smalltalk Collection hierarchy to the Perl 6 core dist.</p>
<p><a href='http://groups.google.com/groups?threadm=20021030094931.Y32444-100000@megazone23.bigpanda.com' target='_blank'>groups.google.com</a></p>
<a name='Persistence of superpositions'></a><h2>Persistence of superpositions</h2>
<p>Buddha Buck wondered how pervasive superpositions were, and for how
long they would remain entangled. Damian thinks they should be all
pervading and fully propagating. This thread didn't really stay very
on topic...</p>
<p><a href='http://groups.google.com/groups?threadm=3DBEF820.3040502@14850.com' target='_blank'>groups.google.com</a></p>
<a name='Proposal: Vector operators for Hashes'></a><h2>Proposal: Vector operators for Hashes</h2>
<p>Arcadi made some proposals about how to extend the concept of vector
operators to Hashes as well as lists and arrays. Discussion
ensued. People seem to like the idea of extending vector ops to cover
hashes, but weren't necessarily sure that Arcadi's approach was the
right one. 'Adverbial' control of how the vector ops work was also
discussed, though Larry gave the impression that he thought this might
be a generalization too far...</p>
<p><a href='http://groups.google.com/groups?threadm=15808.18541.314762.704302@figaro.weizmann.ac.il' target='_blank'>groups.google.com</a></p>
<a name='Plaintive whine about for syntax'></a><h2>Plaintive whine about <code>for</code> syntax</h2>
<p>Dave Storrs really doesn't like the syntax of the `parallel streams'
variant of <code>for</code>:</p>
<pre>    # This iterates over @a and @b in parallel

    for @a; @b -&gt; $x is rw; $y { $x = $y[5] } </pre>
<p>and he offered a list of suggestions, though I think more people
disliked his alternatives (even among those who didn't like the
current syntax) than liked 'em. Damian pointed out that a little
finesse with the editor could be of some assistance:</p>
<pre>    for @a      ; @b       
     -&gt; $x is rw; $y { ... }</pre>
<p>Ed Peshko wondered what happened when you had a lot of parallel
streams, and Damian obliged with:</p>
<pre>    for  @a;  @b;  @c;  @d;  @e
     -&gt;  $a_var1 is rw, $a_var2 is rw;
              $b_var is rw;
                   $c_var is rw;
                        $d_var is rw;
                             $e_var1 is rw, $e_var2 is rw 
    {
        ...
    }</pre>
<p>But this is a somewhat pathological case. Damian also mentioned that
he and Larry had thought long and hard about whether or not to
interleave sources and iterators before deciding on the current
syntax.</p>
<p><a href='http://groups.google.com/groups?threadm=20021030102958.U32444-100000@megazone23.bigpanda.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=3DC19847.7040100@conway.org' target='_blank'>groups.google.com</a></p>
<a name='Nondeterministic algorithms, flexops, and stuff'></a><h2>Nondeterministic algorithms, flexops, and stuff</h2>
<p>Piers Cawley made heads hurt (his included) when he posted a question
about using superpositions (aka flexops) to implement non deterministic
algorithms. The particular example given was an algorithm to find a
path between two nodes of an acyclic directed graph (lifted from a
text on lisp). Jonathan Scott Duff thought the idea was 'neat'. For an
encore, Piers redid the function without flexops, using a continuation
based implementation of <code>choose</code> and <code>fail</code> (which hurts my head
more than the superposition based version, frankly).</p>
<p><a href='http://groups.google.com/groups?threadm=84hef4j96p.fsf@despairon.bofh.org.uk' target='_blank'>groups.google.com</a></p>
<a name='Primitive Boolean type?'></a><h2>Primitive Boolean type?</h2>
<p>Michael Lazzaro asked a tricky question, can a <code>bit</code> be undefined? If
so, then it leads to the somewhat counterintuitive assumption that one
would need two bits to store a single `bit'. Which is certainly
odd. However, it turns out that native types like <code>bit</code>, <code>int</code>, etc
cannot be undefined, so that's all right. This then branched off into
a discussion of whether Perl 6 would have an explicit Boolean
type. It won't. Unless Larry changes his mind.</p>
<p><a href='http://groups.google.com/groups?threadm=31FAE3A3-ED22-11D6-8C8F-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='Labelled if blocks'></a><h2>Labelled if blocks</h2>
<p>Last week, Steve Canfield wondered if Perl 6 would have labelled if
blocks, which would allow one to jump out of arbitrary levels of
nested ifs. It seems the answer is `no', but this led to a discussion
of possible control statements which affect the flow of control in
different sorts of blocks (subs, conditionals, loops, etc.). It's
looking like we may end up with a <code>leave</code> statement. The other
possibility would be to make return a method, allowing one to do:</p>
<pre>    Loop.return($x)</pre>
<p>or whatever.</p>
<p><a href='http://groups.google.com/groups?threadm=Pine.LNX.4.44.0210280903190.15960-100000@london.wall.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=Pine.LNX.4.44.0210281614510.18296-100000@london.wall.org' target='_blank'>groups.google.com</a></p>
<a name='In Brief'></a><h1>In Brief</h1>
<p>There was some disCcussion on the internals list about what functions
need to have an interpreter argument. The basic rule appears to be `if
it's going to allocate memory, it needs an interpreter'.</p>
<p>Leopold Toetsch has rejigged the startup procedure so that we will
always have a valid interpreter, making patches like the one that
allowed for a NULL interpreter in <code>sprintf</code> unnecessary.</p>
<p>Discussion of the Parrot Copyright/License changes was subdued,
bordering on the nonexistent. Lets hope it stays as smooth.</p>
<p>Leo Toetsch has been doing various refactorings of Parrot ops.</p>
<p>There was discussion about how to generate the MD5 hashes for parrot
bytecode `fingerprints'. The catch is that the Perl module
<b>Digest::MD5</b> isn't guaranteed to be available on all Perl
installations...</p>
<p>Josh Wilmes did a massive 'indentation clean up' patch (2000+ line
patch).</p>
<p>Allison Randal has a fascinating article all about Perl 6 topics and
topicalizers at <a href='http://www.perl.com/pub/a/2002/10/30/topic.html,' target='_blank'>www.perl.com</a>
which is well worth the read.</p>
<p>Paul Johnson had some thoughts about using properties on statements
and the like as a way of providing metadata to things like code
coverage tools.</p>
<a name='Who's Who in Perl 6?'></a><h1>Who's Who in Perl 6?</h1>
<ul>
<li><a name='Who are you?'></a>Who are you?</li>
<p>Mike Lazzaro.  My wife and I own a company called Cognitivity
(<a href='http://www.cognitivity.com/)' target='_blank'>www.cognitivity.com</a> in Burbank, California -- we met at
Caltech, in Pasadena.  We use Perl5 for our commercial e-learning
software (online, customizable corporate training software).  This is
the first company we actually own, after working as
consultants/contractors/employees for years at other places.  It's
great.</p>
<li><a name='What do you do for/with Perl 6?'></a>What do you do for/with Perl 6?</li>
<p>Originally, I just wanted to document Perl6's OO behaviours, but I soon
found that to be impossible without documenting everything else first,
so that's what I'm doing.  I'm going piece-by-piece through all the
early Apocalypses, attempting to fill in all the details and
implications, which I am writing up in book-like form.  As I get them
done, I'll post them for review and feedback -- but before that, I'll
have a lot of little questions and inconsistencies that I need to pin
down.</p>
<p>My feeling is, because I'm *not* on the design team, and I *don't*
know all the thinking on how and why things are decided, I'm a good
test person to write newbie-level documentation.  If you can explain
it to me, that's a pretty good indication that you and I can explain
it to someone else.  I think the disconnection between designer and
documenter will be important, in this case, because we want Perl6 to
be heavily adopted by mere mortals, not just experts.</p>
<li><a name='Where are you coming from?'></a>Where are you coming from?</li>
<p>I've been using Perl since the 4 to 5 migration.  Before that, I was
mainly a C/C++ person.  Before that, assembler.  Perl5 is the best
language I've ever used, but lately it's had some enterprise-level
scalability problems that I need to solve, if I'm going to keep using
it.  Hence, I'm helping with Perl6.</p>
<li><a name='When do you think Perl 6 will be released?'></a>When do you think Perl 6 will be released?</li>
<p>Sooner than people think... maybe a robust alpha within six months, I
bet.  People are worried about the length of time it's taking to get
through the initial decisions, but most of the hard ones have already
been done.  It's going to pick up dramatically after the next two or
three Apocalypses.</p>
<li><a name='Why are you doing this?'></a>Why are you doing this?</li>
<p>Because I've had to work in five different languages over the past few
years, and they all suck, each in their own special way.  Horribly.
If I'm going to continue programming as a career, I want to work in a
language that, as much as possible, takes the grunt work out.  I don't
like re-solving the same design patterns umpteen times.  That's
something a computer should do for me.</p>
<p>Why am I volunteering for documentation?  Dunno, seemed like that
effort was falling behind, since everyone keeps asking the same
questions, over and over (like me, for example).  And I can type fast.
And I've got lots of experience at herding cats, which can't hurt...</p>
<li><a name='You have 5 words. Describe yourself.'></a>You have 5 words. Describe yourself.</li>
<p>Programmer, Manager, Writer, Optimist, Cynic.</p>
<li><a name='Do you have anything to declare?'></a>Do you have anything to declare?</li>
<p>I've grown to hate most technical terms, because nobody uses them to
mean the same way.  So I have an allergic reaction to descriptions
that use a lot of big words to explain something that should be Much
More Obvious.  You'll find I post a lot of &quot;please clarify&quot; messages,
to try to beat that out of people.  :-) It doesn't <i>always</i> mean I'm
dense, though sometimes it does.  Sometimes it means &quot;No -- really.
Is that your final answer?&quot;</p>
</ul>
<a name='Acknowledgements, requests and the third thing.'></a><h1>Acknowledgements, requests and the third thing.</h1>
<p>This summary was once again brought to you from the comfort and
security of a GNER Express train running between Newark and London,
and from the greater comfort and security of my armchair at
home. Production was abetted by industrial quantities of site tea (in
the case of GNER) and Earl Grey China Moon tea (in the armchair).</p>
<p>Proofreading was mostly done by Piers Cawley, so you can blame him if
there are any outrageous typos.</p>
<p>And, as the postamble usually goes, if you didn't like this summary,
what are you doing still reading it? If you did like it, please
consider one or both of the following options:</p>
<ul>
<li><a name='Send money to the Perl Foundation at donate.perl-foundation.org/ and help support the ongoing development of Perl 6.'></a>Send money to the Perl Foundation at
<a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> and help support the ongoing
development of Perl 6.</li>
<li><a name='Send feedback, flames, money and/or a tenchi-masa goban with a set of thickish yuki grade shell and slate stones in Shimakuwa bowls to mailto:<a href='mailto:pdcawley@bofh.org.uk.'>pdcawley@bofh.org.uk.</a>'></a>Send feedback, flames, money and/or a tenchi-masa goban with a set of
thickish yuki grade shell and slate stones in Shimakuwa bowls to
mailto:<a href='mailto:pdcawley@bofh.org.uk.'>pdcawley@bofh.org.uk.</a></li>
</ul>
<p>The feed paid for publication of these summaries on perl.com is paid
directly to the Perl Foundation.</p>
</div>
